[Previous] [Next] [Index] [Thread]

Re: User Auth.

On Tue, 26 Mar 1996, Nathan Neulinger wrote:

> I've suggested a "Unauthenticate"  menu option to netscape many times, but
> it's not like they ever listen to users.
> 
> -- Nathan

This is a great idea.  Anyone suggested this to Netscape and the others? 
How about an HTTP Pragma token as well:

Pragma: unauthenticate=1

Presumably, a smart browser would then know that the server or CGI wants
to clear the authentication string and do it if the user has set the
"Accept Clear Authentication" security preference.  This pref should live
next to the "Clear Authentication Cache" button.  

In fact, if I remember right, the base64 encoded Authentication: cookie is
NOT cleared from the browser when the broswer leaves the authenticated
realm? If the Authorization string is sent to EVERY server or CGI until it
runs into a new URI in an authenticated realm, I'd consider this cause for
concern. 

For example, say I wanted to gain access to a realm that I knew the name
of (because I had earlier been prompted for the authentication for the
name of the realm). Couldn't I write a server (a CGI won't work, all
servers I've encountered do not pass the Authorization: base64 cookie to a
CGI) that sends a WWW-Authenticate: header to the client?  I could set up
a site that contains information closely related to that contained at a
URI in the authenticated realm I'm after.  This would attract people who
are likely to have been in the other realm and, therefore, to have an
authentication cookie cached in their browser.  Of course, most other
browsers would not have the Authorization: cookie cached and would
therefore simply prompt the user for the authentication string.  Who
knows, some clever, curious user might even volunteer it to gain access to
the "related" information on my "server".  Then I log all the
Authorization strings, decode them, and use one I want to gain access to
the realm I'm after. 

I realize this is crude. But does anyone see any reason it isn't possible?

I understand the caching of the Authentication base64 cookie is meant to
keep the authentication dialogue from being required for every page in a
ACF restricted realm. But, the addition of an option to clear this seems
logical.  Perhaps the Authentication cookie is cleared when the user
clears his/her cache.  I'd be interested to find this out. If so, this
seems like a lot to throw out just to clear a 74+ byte Authentication
cookie. 

Ideas? Have I lost it...?  :)

Here's the 1.1 HTTP Authentication specs (in case you'd rather not look it 
up):

10.6  Authorization

   A user agent that wishes to authenticate itself with a 
   server--usually, but not necessarily, after receiving a 401 
   response--may do so by including an Authorization request-header 
   field with the request. The Authorization field value consists of 
   credentials containing the authentication information of the user 
   agent for the realm of the resource being requested.

       Authorization  = "Authorization" ":" credentials

   HTTP access authentication is described in Section 11. If a request 
   is authenticated and a realm specified, the same credentials should 
   be valid for all other requests within this realm.

   Responses to requests containing an Authorization field are not 
   cachable.

[..snip..]

11.  Access Authentication

   HTTP provides a simple challenge-response authentication mechanism 
   which may be used by a server to challenge a client request and by 
   a client to provide authentication information. It uses an 
   extensible, case-insensitive token to identify the authentication 
   scheme, followed by a comma-separated list of attribute-value pairs 
   which carry the parameters necessary for achieving authentication 
   via that scheme.

       auth-scheme    = token

       auth-param     = token "=" quoted-string

   The 401 (unauthorized) response message is used by an origin server 
   to challenge the authorization of a user agent. This response must 
   include a WWW-Authenticate header field containing at least one 
   challenge applicable to the requested resource.

       challenge      = auth-scheme 1*SP realm *( "," auth-param )

       realm          = "realm" "=" realm-value
       realm-value    = quoted-string

   The realm attribute (case-insensitive) is required for all 
   authentication schemes which issue a challenge. The realm value 
   (case-sensitive), in combination with the canonical root URL of the 
   server being accessed, defines the protection space. These realms 
   allow the protected resources on a server to be partitioned into a 
   set of protection spaces, each with its own authentication scheme 
   and/or authorization database. The realm value is a string, 
   generally assigned by the origin server, which may have additional 
   semantics specific to the authentication scheme.

   A user agent that wishes to authenticate itself with a 
   server--usually, but not necessarily, after receiving a 401 or 411 
   response--may do so by including an Authorization header field with 
   the request. The Authorization field value consists of credentials 
   containing the authentication information of the user agent for the 
   realm of the resource being requested.

       credentials    = basic-credentials
                      | auth-scheme *("," auth-param )

   The domain over which credentials can be automatically applied by a 
   user agent is determined by the protection space. If a prior 
   request has been authorized, the same credentials may be reused for 
   all other requests within that protection space for a period of 
   time determined by the authentication scheme, parameters, and/or 
   user preference. Unless otherwise defined by the authentication 
   scheme, a single protection space cannot extend outside the scope 
   of its server.

   If the server does not wish to accept the credentials sent with a 
   request, it should return a 401 (unauthorized) response. The 
   response must include a WWW-Authenticate header field containing 
   the (possibly new) challenge applicable to the requested resource 
   and an entity explaining the refusal.

   The HTTP protocol does not restrict applications to this simple 
   challenge-response mechanism for access authentication. Additional 
   mechanisms may be used, such as encryption at the transport level 
   or via message encapsulation, and with additional header fields 
   specifying authentication information. However, these additional 
   mechanisms are not defined by this specification.

   Proxies must be completely transparent regarding user agent 
   authentication. That is, they must forward the WWW-Authenticate and 
   Authorization headers untouched, and must not cache the response to 
   a request containing Authorization.

   HTTP/1.1 allows a client pass authentication information to and 
   from a proxy via the Proxy-Authenticate and Proxy-Authorization 
   headers.

11.1  Basic Authentication Scheme

   The "basic" authentication scheme is based on the model that the 
   user agent must authenticate itself with a user-ID and a password 
   for each realm. The realm value should be considered an opaque 
   string which can only be compared for equality with other realms on 
   that server. The server will service the request only if it can 
   validate the user-ID and password for the protection space of the 
   Request-URI. There are no optional authentication parameters.

   Upon receipt of an unauthorized request for a URI within the 
   protection space, the server should respond with a challenge like 
   the following:

       WWW-Authenticate: Basic realm="WallyWorld"

   where "WallyWorld" is the string assigned by the server to identify 
   the protection space of the Request-URI.

   To receive authorization, the client sends the user-ID and 
   password, separated by a single colon (":") character, within a 
   base64 [7] encoded string in the credentials.

       basic-credentials = " Basic" SP basic-cookie

       basic-cookie      = <base64 [7] encoding of userid-password,
                           except not limited to 76 char/line>

       userid-password   = [ token ] ":" *TEXT

   If the user agent wishes to send the user-ID "Aladdin" and password 
   "open sesame", it would use the following header field:

       Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

   The basic authentication scheme is a non-secure method of filtering 
   unauthorized access to resources on an HTTP server. It is based on 
   the assumption that the connection between the client and the 
   server can be regarded as a trusted carrier. As this is not 
   generally true on an open network, the basic authentication scheme 
   should be used accordingly. In spite of this, clients should 
   implement the scheme in order to communicate with servers that use 
   it.

11.2  Digest Authentication Scheme

   The "digest" authentication scheme is [currently described in an 
   expired Internet-Draft, and this description will have to be 
   improved to reference a new draft or include the old one].

[..snip..]


Robert Muhlestein
Teleport Creative Services
CGI/Java Guy
cgi@teleport.com
References: